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Abstract —  Cognitive  Radios  and  Networks  have  become  a  focus 
of  attention  commercially  and  within  DoD.  Technologies  such  as 
Dynamic  Spectrum  Access  (DSA)  can  greatly  improve  spectrum 
utilization  and  can  even  address  issues  such  as  Anti-Jam.  One  of 
the  most  difficult  tasks  ahead  of  us  is  to  manage  these  cognitive 
systems.  Rules  or  "policies"  must  be  used  to  control  them,  but 
these  policies  must  be  balanced  with  the  intelligence  innate  within 
cognitive  systems  so  as  not  to  thwart  performance.  Typical 
network  policies  use  an  event-condition-action  (ECA)  format.  But 
cognitive  policies  are  often  written  using  a  “permissive  / 
restrictive”  format  that  is  declarative  stating  the  type  of  behavior 
desired  rather  than  how  to  implement  the  behavior.  How  such 
policies  are  developed,  distributed,  and  maintained  is  an  active 
area  of  investigation  within  DoD.  This  paper  will  present  work 
investigating  the  components  required  in  a  DoD  system  to 
implement  a  policy  management  framework  for  DSA  systems 
and  it  extensibility  to  other  cognitive  systems. 1 
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I.  Introduction 

Recent  efforts  in  cognitive  radio  have  focused  on  “White 
Space”:  Spectrum  that  is  allocated  for  use  by  others  but  is 
locally  unoccupied  at  the  current  time.  A  critical  technology 
for  accessing  white  space  is  dynamic  spectrum  access  (DSA). 
US  Department  of  Defense  (DoD)  efforts  such  as  the  DARPA 
XG  program  [1]  and  commercial  standards  efforts  such  as 
IEEE  802.22  [2]  and  IEEE  1900.4  [3]  have  placed  a  focus  on 
DSA  technology.  However,  the  roots  of  DSA  stretch  farther 
back. 

For  many  years  commercial  standards  such  as  802.11  have 
had  the  ability  to  detect  systems  such  as  military  radars,  and 
relocate  the  wireless  data  network  in  response  [4].  Such 
systems  meet  some  definitions  of  DSA  and  cognitive  radio  [5]. 
What  differentiates  current  DSA  efforts  is  the  emphasis  on 
reprogramability  via  policy,  and  how  DSA  systems  are 
managed  [6]  [7]  . 

DSA  systems  present  a  number  of  challenges  for  control 
and  management.  One  is  that  as  policies  become  more  complex 
a  simple  imperative  “set/get”  approach  to  controlling  radios  is 
no  longer  appropriate.  Rather  declarative  approaches  are 
preferred. 
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For  instance,  in  a  traditional  radio  system,  the  operating 
frequency  would  be  programmed  via  an  external  interface.  In  a 
DSA  radio,  a  set  of  operating  frequencies  and  conditions  would 
be  provided.  The  radio  system  then  determines  what  specific 
frequency  to  use  based  on  its  environment  and  state. 

The  selection  of  operating  frequency  could  be  based  on 
many  criteria.  Some  examples  would  be  propagation 
conditions,  received  interference,  interference  to  other  systems, 
current  location,  current  time,  mission  constraints,  etc.  The 
specific  criteria  may  vary  over  time.  The  desire  to  express 
complex  constraints  leads  to  a  “declarative”  approach  to 
controlling  DSA  radios.  The  type  of  behavior  desired  is 
expressed  rather  than  how  to  achieve  that  behavior. 

Another  management  and  control  issue  is  that  many 
different  entities  may  have  an  interest  in  influencing  the  radios 
behavior.  Regulators,  spectrum  planners,  network  planners, 
mission  planners,  and  the  immediate  user  may  all  want  to 
influence  the  behavior  of  the  radio.  A  framework  and 
architecture  are  required  to  ensure  effective  control  and 
management  of  DSA  radios.  For  DoD  networks,  the 
framework  should  reflect  the  command  and  control  structure 
innate  within  DoD. 

To  address  these  issues  a  study  was  conducted  by  the 
authors  to  identify  an  appropriate  framework  and  architecture 
for  policy  management  of  DoD  DSA  systems.  While  the 
results  were  targeted  for  application  to  DSA  radios,  they  are 
sufficiently  general  that  they  could  be  applied  to  the  control  of 
many  cognitive  systems.  This  paper  reports  some  of  those 
results  from  that  study  [8].  The  rest  of  this  paper  is  organized 
as  follows. 

Section  II  reviews  some  relevant  issues  pertaining  to  policy 
engines  and  languages.  Section  III  reviews  the  use  cases 
developed  for  the  study.  Section  IV  reviews  a  tiered  policy 
distribution  architecture  developed  on  the  study.  Section  V 
presents  the  generic  policy  framework  that  was  developed. 
And  Section  VI  provides  a  summary  and  some  conclusions. 

II.  Policy  Engines  and  Languages 

Two  core  components  of  any  policy  management 
framework  are  the  policy  engines  used  to  process  policy,  and 
policy  language  or  languages  used  to  express  policy.  A  wide 
variety  of  architectures  for  policy  engines  exist  (e.g.  [4]-[7], 
[9],  and  [10]).  No  single  authoritative  definition  of  a  policy 
engine  seems  to  exist  today. 
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Figure  1 .  Example  Cognitive  Engine  Model 


A  good  general  reference  for  terms  relating  to  DSA  and 
cognitive  radio  is  [5].  There  the  term  “policy  engine”  does  not 
exist,  with  the  closest  equivalent  being  “policy  based  control 
mechanism”.  This  is  defined  as: 

“A  mechanism  that  governs  radio  behavior  by  sets  of  rules, 
expressed  in  a  machine-readable  format,  that  are  independent 
of  the  radio  implementation  regardless  of  whether  the  radio 
implementation  is  in  hardware  or  software.” 

The  policy  based  control  mechanism  is  described  as  a 
component  of  a  ‘cognitive  engine”  which  itself  is  part  of  an 
“adaptive  radio”  (see  Figure  B.5  of  [5]).  However,  the  concept 
of  a  policy  engine  is  well  established  (e.g.  [6]  chapter  6). 
Within  DoD  circles  most  cognitive  radio  architectures  have  a 
portion  of  the  radio  allocated  to  dealing  with  policy,  which  we 
here  term  a  policy  engine.  Most  of  these  are  derivatives  from 
the  cognitive  engine  concepts  developed  on  the  DARPA  neXt 
Generation  (XG)  program.  A  reference  model  was  required  for 
our  investigations,  and  we  adopted  a  model  based  on  [8]  which 
is  derived  from  the  XG  cognitive  engine.  The  essence  of  this 
model  is  shown  in  Figure  1. 

A  key  aspect  of  the  model  is  the  partitioning  of  the 
reasoning  between  a  “System  Strategy  Reasoner”  (SSR)  and  a 
“Policy  Conformance  Reasoner”  (PCR).  The  SSR  focuses  on 
deciding  the  appropriate  behavior  for  the  radio  system.  When  a 
transmission  (or  set  of  transmissions)  is  required,  the  SSR 
queries  the  PCR  as  to  whether  the  set  of  transmissions  (with 
transmission  parameters)  conforms  with  all  the  policies  the 
radio  must  meet.  Minimally  the  PCR  must  respond  with  a 
“yes”  or  “no”  answer.  Other  answers  could  include  “yes  if’ 
where  the  SSR  provides  a  incomplete  set  of  parameters,  and  the 
PCR  provides  a  response  with  what  the  missing  parameters 
need  to  be  to  fulfill  all  policy  requirements.  One  output  of  this 
study  was  that  a  “no,  because”  output  should  be  considered. 
This  would  detail  the  specific  policies  that  a  requested 
transmission  would  be  in  violation  of  if  allowed.  Such  a 
response  would  allow  the  SSR  to  more  quickly  converge  to  an 
acceptable  set  of  transmission  parameters. 


Another  potential  component  of  the  policy  engine  is  the 
“policy  enforcer”  [7].  This  component  would  have  the  ability 
to  gate  outgoing  transmissions  to  confirm  they  are  compliant 
with  policy.  As  of  the  writing  of  this  article,  debate  is  still 
ongoing  in  standards  bodies  such  as  IEEE  P1900.5  as  to 
whether  this  component  should  be  included  in  their  reference 
model. 

While  the  model  in  Figure  1  was  adopted  for  this  study  and 
has  been  shown  to  be  implementable  [1],  our  sense  is  that  the 
industry  has  not  yet  converged  on  a  model  for  a  policy  engine. 
A  primary  motivator  for  the  partitioning  in  the  model  seems  to 
have  been  certification  of  the  policy  decision  making  [7].  One 
concern  expressed  in  the  study  is  that  to  be  efficient  the  SSR 
and  PCR  need  to  be  tightly  coupled.  The  test  results  in  [11] 
suggest  that  if  the  SSR  and  PCR  are  not  tightly  coupled,  radios 
may  not  be  able  to  make  decisions  in  a  timely  manner.  Also,  if 
the  “no,  because”  response  were  implemented,  it  is  believed  the 
SSR  would  benefit  from  direct  interaction  with  the  policies. 

Based  on  our  analysis,  we  believe  the  SSR  and  PCR  need  to 
interact  heavily  and  deeply.  The  partitioning  in  the  reference 
model  should  be  considered  a  “logical”  partitioning.  It  is  not 
necessarily  recommended  for  guidance  in  implementation. 
Further  study  in  this  area  is  required. 

Another  observation  from  the  study  was  that  the  language 
selected  to  express  policies  and  the  reasoning  used  to  evaluate 
the  policies  is  coupled  to  some  degree.  Typical  network 
policies  use  an  event-condition-action  (ECA)  format  (e.g.  [6] 
chapter  6  and  [12]).  But  as  shown  in  Figure  1,  the  policy 
decisions  are  tailored  around  being  allowed  to  transmit,  or  not 
allowed  to  transmit.  Policies  for  current  XG  derived  activities 
are  written  using  a  “permissive  /  restrictive”  format  that  is 
declarative  of  whether  the  radio  should  or  should  not  be 
allowed  to  transmit.  Evidence  (akin  to  conditions  in  ECA)  is 
presented  by  the  SSR  for  transmissions  decisions.  Based  on 
the  policies,  evidence,  and  transmission  requested  the  PCR  then 
makes  a  decision  on  transmission. 
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Figure  2.  Use  cases  relating  a  spectrum  manager  to  a  policy  user 


To  support  the  declarative  nature  of  the  policies  and  take 
advantage  of  the  reprogramability  assumed  within  the  DSA 
radios,  an  ontology  is  used  to  define  objects  and  relationships 
which  are  used  to  express  the  semantics  of  the  policies.  Today, 
the  Web  Ontology  Language  (OWL)  augmented  by  various 
extensions  is  typically  used  for  this  purpose.  However  it  is 
observed  that  these  languages  are  tailored  towards  specific 
types  of  reasoning,  such  as  description  logic.  As  such  they  are 
limiting  in  the  use  of  other  types  of  reasoning. 

There  was  not  sufficient  time  in  the  study  to  thoroughly 
evaluate  and  trade  off  different  languages  for  use  in  expressing 
DSA  policy.  Rather  a  number  of  reason  and  language  options 
were  catalogued  [8].  It  is  expected  that  the  preferred  format 
will  evolve  over  time,  but  currently  a  combination  of  a  version 
of  Web  Ontology  Language  (OWL)  supplemented  with  the 
Semantic  Web  Rule  Language  (SWRL)  encapsulated  within 
Extensible  Markup  Language  (XML)  is  believed  sufficient  and 
preferred.  Further  study  is  desirable  in  this  area. 

In  addition,  human  readable  format  of  policy  along  with 
translation  to/from  machine  readable  formats  are  required.  It  is 
believe  additional  work  is  still  required  in  this  area.  Finally  it 
is  noted  that  the  language  used  for  evaluating  the  policies  may 
be  different  than  the  language  used  to  express  them.  It  did  not 
appear  critical  that  the  language  for  policy  evaluation  be 
specified,  so  it  was  not  considered  in  developing  the  policy 
management  framework  discussed  here. 

in.  Use  cases 

The  first  step  in  developing  a  framework  should  be  to 
develop  use  cases  for  the  framework.  Typical  use  cases  for 
DSA  focus  on  the  RF  environment  and  how  radios  react  to  that 
environment.  But,  for  a  policy  management  framework  the  use 
cases  developed  must  focus  on  the  development,  deployment, 
and  maintenance  of  policy  rather  than  the  specific  behavior  of 
the  radios. 

To  develop  use  cases  we  first  focused  on  identifying  who 
the  “Actors”  are  in  the  use  cases.  Who  needs  to  interact  with 
DSA  policy  as  part  of  its  use?  While  we  normally  think  of 
regulators  as  being  the  primary  creators  of  policy,  spectrum 
managers  actually  play  a  more  active  role.  While  regulators 
such  as  the  FCC,  NTIA,  or  ITU  create  top  level  policy, 
spectrum  managers  must  create  additional  regional  or  local 
policy  that  are  consistent  with  regulatory  policy.  In  addition, 
spectrum  managers  are  likely  to  be  responsible  for  distribution 
of  policy.  So  the  use  cases  we  developed  focused  on  the 
spectrum  manager. 


Creation  of  DSA  policy  is  very  much  a  part  of  spectrum 
management.  To  that  end  a  useful  document  is  “Pub  8”  [13] 
which  details  a  standard  spectrum  resource  format,  but  more 
importantly  here  identifies  typical  relationships  between 
spectrum  planning  entities. 

In  the  end  we  decided  there  are  4  key  activities  a  spectrum 
manager  needs  to  do  that  can  interact  with  policy.  Those  are 
planning,  engineering,  authorization,  and  monitoring.  We  see 
the  needs  of  a  regulator  as  being  a  similar  but  perhaps  more 
constrained  subset  of  the  activities  required  for  a  manager.  The 
relationship  between  a  spectrum  manager  and  policy  user 
(really  the  policy  itself)  is  shown  in  Figure  2.  Ultimately  we 
believe  the  DSA  policy  framework  developed  should  support 
all  the  activities  identified  here. 

IV.  Policy  management  tiers 

One  thing  that  became  apparent  in  our  study  was  the  need 
to  have  a  tiered  architecture  for  DSA  policy  management. 
There  are  several  reasons  for  this.  The  first  is  that  spectrum 
management  organizations  are  hierarchical.  In  the  top  tier  are 
regulatory  agencies  such  as  at  the  FCC,  NTIA  and  ITU. 
Regulatory  agencies  accept  input  from  a  number  of  advisory 
organizations  and  user  groups.  They  tend  to  set  policy  in  a 
very  broad  context,  and  not  change  it  very  often.  The 
regulatory  policies  then  flow  down,  normally  to  spectrum 
planners. 

Under  the  regulators  are  spectrum  managers  or  system 
operators.  Typically  there  are  multiple  sets  of  managers  / 
operators  for  different  organizations  that  may  interrelate  as 
peers,  or  superordinate  /  subordinate.  Spectrum  managers 
must  perform  a  planning  function  to  allocate  spectrum  to  users. 
They  must  also  interact  with  other  types  of  planners  such  as 
network  planners  and  mission  planners. 

In  the  end  it  was  determined  that  there  should  be  two 
distinct  tiers  -  A  “regulatory”  tier,  and  a  “planning”  tier.  The 
planning  tier  is  subordinate  to  the  regulatory  tier  and  only 
loosely  interacts  with  it.  Within  the  planning  tier  can  be  a 
complex  array  of  interactions.  But  the  ultimate  outcome  is  a 
set  of  policy  that  must  be  pushed  down  to  the  policy  users. 
Policy  at  this  tier  is  generated  and  modified  more  frequently 
than  at  the  regulatory  tier,  and  must  be  generated  in  a  machine 
readable  format  that  can  be  delivered  to  the  policy  user.  It  is 
expected  that  human  beings  will  be  responsible  for  generation 
of  policy  at  both  this  tier  and  the  regulatory  tier. 
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Figure  3.  The  recommended  tiered  policy  distribution  architecture 


Once  generated,  policy  must  be  delivered  to  the  policy 
users.  Generally  a  network  of  some  sort  will  be  used  to 
accomplish  the  distribution  of  policy.  However,  more  than 
distribution  is  generally  required.  Control  and  monitoring 
functions  are  typically  required  as  well.  There  may  be  different 
versions  of  policy  that  must  be  tracked  in  terms  of  which  users 
have  received  which  version  of  policy.  In  addition,  feedback 
on  policy  /  radio  performance  may  be  desired.  Feedback  could 
be  acted  upon  if  corrective  actions  are  required.  This  feedback 
may  or  may  not  be  pushed  back  up  to  the  planning  tier.  So  it 
seems  a  tier  for  monitoring  /  control  needs  to  exist  as  well. 

To  accommodate  these  needs  a  “management”  (command 
and  control)  tier  is  recommended,  that  may  be  loosely  coupled 
to  battle  command  and  control,  or  network  management.  This 
tier  woidd  exist  below  the  planning  tier.  It  is  seen  as  primary 
reactive  rather  than  proactive,  and  will  ultimately  require 
response  times  that  cannot  be  accommodated  with  a  human 
being  in  the  loop.  Little  to  no  changes  in  policy  are  expected  at 
this  tier  today.  However  it  is  envisioned  that  as  spectrum 
planning  becomes  more  automated  real  time  spectrum  planning 
will  become  possible.  Proactive  management  of  DSA  Policy 
(detecting  in  advance  when  changes  to  DSA  policy 
configuration  are  required)  may  also  be  incorporated.  If  real 
time  spectrum  planning  and  proactive  management  of  DSA 
policy  do  occur,  they  may  be  incorporated  at  the  “top”  of  the 
management  tier,  or  alternatively  at  the  “bottom”  of  the 
planning  tier. 

At  the  lowest  level  in  this  tiered  distribution  architecture  are 
the  policy  users  or  end  points.  We  call  this  the  “execution”  tier 
because  it  is  where  policy  is  implemented  and  enforced.  Policy 
users  accept  and  enforce  policy,  but  today  don’t  have  the 
ability  to  change  policy.  The  sum  result  of  this  analysis  is 
shown  in  Figure  3  where  the  recommended  tiered  policy 
distribution  architecture  is  presented. 


V.  A  Policy  Management  Framework 

While  the  distribution  architecture  gives  a  sense  of  the  flow 
of  policy,  it  does  not  address  the  components  required  to 
implement  a  DSA  policy  management  system.  Identifying 
those  components  is  critical  if  a  DSA  policy  management 
system  is  to  be  specified  and  procured. 

To  help  in  the  ultimate  specification  and  procurement  of  a 
DSA  policy  management  system  a  framework  was  developed 
which  attempts  to  identify  all  the  critical  components  that  must 
exist  to  implement  a  working  system.  The  framework  is  very 
generic,  and  further  work  is  required  to  map  it  to  specific 
architectural  elements  for  a  given  implementation.  The  generic 
framework  is  shown  in  Figure  4. 

Starting  at  the  top  left  of  Figure  4,  it  is  expected  that  top 
level  policy  will  be  generated  by  people  rather  than  machines. 
Tools  to  allow  the  creation  and  validation  of  DSA  policy  will 
be  required.  These  tools  ultimately  need  to  generate  policy  in  a 
machine  readable  format.  It  is  expected  that  the  preferred 
format  will  evolve  over  time,  but  currently  a  combination  of  a 
version  of  Web  Ontology  Language  (OWL)  supplemented  with 
the  Semantic  Web  Rule  Language  (SWRL)  encapsulated 
within  Extensible  Markup  Language  (XML)  is  preferred.  The 
tools  will  also  need  to  be  able  to  translate  machine  readable 
expressions  of  policy  into  a  human  readable  format. 

In  addition  to  policy  generation  tools,  policy  based  planning 
tools  will  be  required  (Shown  at  the  middle  top  of  Figure  4). 
Currently  it  is  believe  that  mission,  network,  and  spectrum 
planning  tools  will  need  to  integrate  DSA  policy  as  part  of  their 
planning  process.  In  addition  to  generating  and  viewing  DSA 
policy,  these  tools  may  need  to  emulate  the  impact  of  DSA 
policy  in  various  ways.  This  could  include  modeling  the 
impact  of  running  policies  on  specific  radio  platforms,  and  the 
impact  on  network  performance  /  mission  effectiveness. 
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Figure  4.  Use  cases  relating  a  spectrum  manager  to  a  policy  user 


Once  created,  DSA  policy  will  need  to  be  deployed.  A 
secure  policy  distribution  protocol  is  required  that  can  safely 
operate  over  the  Global  Information  Grid  (GIG).  The  GIG  is 
shown  as  the  cloud  in  the  middle  of  the  diagram.  A  key  point 
is  that  a  wide  variety  of  networked  components  may  need  to 
interact  with  DSA  policy. 

It  is  preferred  that  policy  deconfliction  occur  prior  to 
loading  of  the  policies  in  radios.  Policy  engines  that 
autonomously  deconflict  policy  from  different  sources  prior  to 
final  distribution  to  end  points  seems  likely.  In  addition,  a 
wide  variety  of  DSA  radios  are  expected  to  coexist  in 
deployments.  Some  will  have  greater  cognitive  capabilities 
than  others.  To  accommodate  this,  the  format  of  the  policies 
will  need  to  be  translated  for  different  types  of  radios. 

The  U.S.  Army  Communications-  Electronics  Research, 
Development,  and  Engineering  Center  (CERDEC)  under  the 
RF  ADaptive  Technologies  Integrated  with  Communications 
And  Location  (RADICAL)  ATO-D  [14]  is  developing  a  set  of 
tools  to  assist  in  DSA  policy  generation.  These  include  a 
“Configuration  Generation”  tool  that  will  format  a  given  policy 
set  so  that  it  can  be  properly  accepted  and  interpreted  by 
different  types  of  DSA  radios.  This  concept  is  shown  on  the 
bottom  left  of  Figure  4. 

At  the  extreme,  legacy  (non-DSA)  radios  may  be  given 
DSA  capabilities  through  the  use  of  cognitive  networking 
techniques.  This  is  also  shown  towards  the  bottom  left  of 
Figure  4.  Here  a  policy  reasoner  is  placed  external  to  the  radio, 
along  with  software  to  control  the  radio  via  a  management 
information  base  (MIB).  External  network  databases  (shown  to 


the  left  of  the  figure)  and  sensors  are  used  to  help  determine 
how  to  configure  the  radio.  The  policy  reasoners  would 
network  with  other  policy  reasoners  controlling  legacy  radios 
to  jointly  configure  a  radio  system. 

In  addition  there  may  be  other  components  monitoring  and 
controlling  the  overall  performance  of  sets  of  radios.  These 
devices  would  also  need  access  to  DSA  policy.  They  are 
identified  as  “networked  reasoners”  in  Figure  4. 

While  this  framework  is  targeted  at  DSA  policy  for  DoD, 
many  of  the  components  identified  would  also  be  useful  in 
commercial  networks.  Other  types  of  policy  (such  as  network 
policy)  could  be  incorporated  within  the  same  framework. 
While  the  data  based  identified  (situation  awareness  and  EW) 
may  not  directly  be  relevant  commercially,  they  are  intended  to 
be  exemplary  rather  than  strictly  required.  Commercially, 
“coexistence”  or  “geolocation”  databases  might  be  used 
instead.  The  rest  of  the  framework  has  been  specified  in 
sufficiently  generic  terms  that  commercial  analogs  should  exist 
as  is. 

VI.  Summary  and  Conclusions 

This  paper  has  reviewed  some  of  the  results  from  a  recent 
study  to  develop  a  DSA  policy  management  framework 
conducted  for  DISA  [8].  Key  results  reviewed  included  the 
identification  of  use  cases,  development  of  a  tiered  policy 
distribution  architecture,  and  a  recommended  policy 
management  framework.  Other  investigations  in  that  study  on 
related  topics  including  policy  engines  and  languages  are  not 
reported  here. 
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Much  work  remains  to  be  done  in  this  area.  If  DSA 
systems  are  to  be  employed  in  the  near  term  the  generic 
framework  described  needs  to  be  mapped  to  specific 
infrastructure  that  can  be  procured  or  developed.  In  addition, 
policy  management  approaches  for  cognitive  radios  /  networks 
will  continue  to  evolve.  It  is  believed  that  a  more  generic  policy 
management  approach  incorporating  at  a  minimum  network 
and  spectrum  management  policy,  but  potential  other  policy 
needs  such  as  mission  policy  is  possible.  It  is  an  open  question 
as  to  whether  such  an  encompassing  policy  management 
approach  is  needed. 

The  tier  policy  distribution  architecture  and  policy 
management  framework  have  been  geared  for  DoD.  However 
they  are  quite  generic.  It  is  expected  that  they  could  both  be 
applied  commercially,  but  further  investigation  would  be 
required. 

Finally,  there  is  much  research  yet  to  be  conducted  in 
policy  controlled  cognitive  systems,  particular  concerning 
policy  languages  and  engines.  It  is  difficult  today  to  forecast 
how  policy  management  architectures  will  need  to  evolve  in 
the  long  term  to  account  for  innovations  that  are  likely  to  occur 
here.  Policy  management  for  DSA  and  cognitive  networks  / 
systems  promises  to  be  an  exciting  area  of  research  for  some 
time  to  come. 
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